home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / databases / foxpro.rushmore < prev    next >
Encoding:
Text File  |  1995-07-25  |  13.6 KB  |  379 lines
  1. Subject: FoxPro Databases FAQ #2: See Fox.  See Fox Run.  Run, Fox, Run.
  2. Newsgroups: comp.databases.xbase.fox,comp.answers,news.answers
  3. From: kcochran@nyx10.cs.du.edu (Keith "Justified And Ancient" Cochran)
  4. Date: 2 Nov 1994 00:49:39 -0700
  5.  
  6. Archive-name: databases/foxpro/rushmore
  7. Posting-frequency: Monthly
  8.  
  9. [This is version 1.0.0.2, last updated 07/03/94. New or altered text
  10. is marked with ">" in the left hand column.  Please send all comments,
  11. suggestions, and whatnot to kcochran@nyx.cs.du.edu]
  12.  
  13. One of the most my mysterious things about FoxPro is the Rushmore
  14. Technology.  This FAQ deals with Rushmore, and how to use it to get
  15. every last ounce of power out of your databases.
  16.  
  17. This FAQ is organized in the following manner:
  18.  
  19. 0.0 What is Rushmore?
  20. 0.1 What isn't Rushmore?
  21. 0.2 Why is it called Rushmore?
  22.  
  23. 1.0 How do I turn on Rushmore?
  24. 1.1 Where can I utilize Rushmore?
  25. 1.2 Where can't I utilize Rushmore?
  26. 1.3 How do I turn off Rushmore?
  27.  
  28. 2.0 Simple indexes and Rushmore.
  29. 2.1 Compound indexes and Rushmore.
  30. 2.2 Complex indexes and Rushmore.
  31.  
  32. 3.0 Using functions in indexes.
  33. 3.1 Using user-defined functions in indexes.
  34. 3.2 Using functions from .plb files in indexes.
  35.  
  36. 4.0 What is an "optimizable expression"?
  37. 4.1 Fully optimizable expressions.
  38. 4.2 Partially optimizable expressions.
  39. 4.3 Non-optimizable expressions.
  40.  
  41. 5.0 Rushmore and the SEEK statement.
  42. 5.1 Rushmore and the LOCATE statement.
  43. 5.2 Rushmore and the SET ORDER TO statement.
  44. 5.3 Rushmore and the SET RELATION TO statement.
  45. 5.4 Rushmore and the SET DELETED statement.
  46.  
  47. [Note each of these sections is seperate with "******"]
  48.  
  49. ******
  50. 0.0 What is Rushmore?
  51.     The "simple" answer:  Rushmore is this little bit of magic that allows
  52.     you main-frame database access speeds on a lowly PC.
  53.  
  54.     The "more complex" answer:  Rushmore is a data-access method that utilizes
  55.     binary selection critera and better index-manipulation methods to allow
  56.     faster resolution of searches.
  57.  
  58.     [If you want to know what the "more complex" answer is really saying,
  59.     take a graduate course in database programming.]
  60.  
  61.     The "correct" answer:  Rushmore is a mountain in South Dakota which has
  62.     been carved into the faces of several presidents. :]
  63.  
  64. ******
  65. 0.1 What isn't Rushmore?
  66.     Rushmore has nothing to do with satanism.
  67.     Rushmore has nothing to do with the power tools.
  68.     Rushmore has nothing to do with your report layouts.
  69.     Rushmore has nothing to do with your mouse or keyboard.
  70.  
  71. ******
  72. 0.2 Why is it called Rushmore?
  73.     Oddly enough, the design team came up with the "code-name" Rushmore
  74.     after spending a night watching the movie "North By Northwest."
  75.  
  76. ******
  77. 1.0 How do I turn on Rushmore?
  78.     You don't.  Any time you can include a FOR clause in a statement,
  79.     Rushmore will try to optimize the expression.
  80.  
  81.     Some exceptions apply.  For example, Rushmore will not activate if
  82.     you have a statement with a WHILE clause in it.
  83.  
  84.     Rushmore works best with .CDX indexes, but it will utilize any open
  85.     .IDX or compact .IDX indexes that it can get its greedy little hands
  86.     upon.
  87.  
  88. ******
  89. 1.1 Where can I utilize Rushmore?
  90.     You can utilize Rushmore in any FoxPro statement that allows a FOR
  91.     clause, or in an SQL statement.  If you are dealing with databases
  92.     of any size, you should utilize Rushmore as often as possible.
  93.  
  94.     Note:  The only way to utilize Rushmore when doing multi-database
  95.     access is through the SQL SELECT statement.
  96.  
  97. ******
  98. 1.2 Where can't I utilize Rushmore?
  99.     Basically, if you can't include a FOR clause, you can't use Rushmore.
  100.  
  101.     Rushmore also can't be used if you have a WHILE clause in your statement,
  102.     or if you are doing a LOCATE on the child table in a multi-table
  103.     relation.
  104.  
  105.     Note that SEEK and GOTO do not utilize Rushmore.
  106.  
  107. ******
  108. 1.3 How do I turn off Rushmore?
  109.     In some rare instances, you may want to turn off Rushmore so that it
  110.     doesn't try to optimize your expression.
  111.  
  112.     In order to do so there are two methods:
  113.  
  114.     SET OPTIMIZE ON|OFF - This turns Rushmore on/off until the next SET
  115.     OPTIMIZE statement is executed.  It is probably not a good idea to
  116.     use this statement.
  117.  
  118.     There is another way to disable Rushmore.  Any statement that can
  119.     utilize Rushmore has a NOOPTIMIZE clause.  This clause will disable
  120.     Rushmore for that statement.  Note that if you have a multi-line
  121.     statement, such as:
  122.  
  123.     SELECT db1
  124.     LOCATE FOR foo=bar NOOPTIMIZE
  125.     WHILE FOUND()
  126.        SELECT db2
  127.        LOCATE FOR date1 = m.mydate
  128.        WHILE FOUND()
  129.           [...]
  130.           CONTINUE
  131.        ENDWHILE
  132.        SELECT db1
  133.        CONTINUE
  134.     ENDWHILE
  135.  
  136.     Rushmore will be disabled for the db1 LOCATE, but will be active for
  137.     the db2 LOCATE.
  138.  
  139.     NB:  Be very wary of using GOTO, LOCATE, SEEK, SKIP or any other command
  140.     that may move the record pointer (like APPEND, or SQL - SELECT) in any
  141.     databases that are linked using SET RELATION TO.  You may not like the
  142.     results.
  143.  
  144. ******
  145. For the following discussions, we have the following database structure:
  146.    fname C(15)
  147.    minit C(1)
  148.    lname C(18)
  149.    dob D
  150.    ssn N(9,0)
  151.  
  152. ******
  153. 2.0 Simple indexes and Rushmore.
  154.     A simple index is of the form:
  155.  
  156.     INDEX ON ssn TAG ssn
  157.  
  158.     This is the type of index that Rushmore likes using the "best".  In
  159.     order to utilize Rushmore with this type of tag, all you have to do
  160.     is:
  161.  
  162.     LOCATE FOR ssn = 987654321
  163.  
  164.     Simple indexes are generally only built on numeric, date, or
  165.     formatted character fields.  For more information on why this is
  166.     so, see sections 2.2, 3.0, and 4.0.
  167.  
  168. ******
  169. 2.1 Compound indexes and Rushmore.
  170.     A coumpound index is of the format:
  171.  
  172.     INDEX ON lname+fname TAG name
  173.  
  174.     In order to utilize this type of tag with Rushmore, you have to:
  175.  
  176.     LOCATE FOR lname+fname = "Cochran Keith"
  177.  
  178.     What's that?  You want to know why you wouldn't use:
  179.  
  180.     LOCATE FOR name = "Cochran Keith"
  181.  
  182.     Well, there's a reason for that, and it's even a good one.  The TAG
  183.     parameter is for your usage. Rushmore understands expressions, not
  184.     tags.
  185.  
  186.     In order to get Rushmore to work, the expression on the left side of
  187.     the expression must match in essence the expression of the INDEX ON
  188.     statement.  So, the following are things that Rushmore can't utilize
  189.     with our current INDEX statement:
  190.  
  191.     LOCATE FOR UPPER(lname+fname) = "COCHRAN KEITH"
  192.     LOCATE FOR LTRIM(lname)+fname = "COCHRAN KEITH"
  193.     LOCATE FOR lname+" "+fname = "Cochran Keith"
  194.  
  195.     For a discussion of how to correctly utilize Rushmore with functions,
  196.     see sections 2.2 and 3.0.
  197.  
  198.     NB: Special care must be taken when creating compound or complex indexes
  199.     with numeric and date fields.  For more information, see the INDEX ON
  200.     section in the FAQ "Things your Mamma never told you".
  201.  
  202. ******
  203. 2.2 Complex indexes and Rushmore.
  204.     A complex index is any index that uses math, string, or other functions
  205.     as part of the index.  Some examples:
  206.  
  207.     INDEX ON DTOS(date) TAG cdate
  208.     INDEX ON lname+", "+fname TAG fullname
  209.     INDEX ON STR(ssn) TAG cssn
  210.     INDEX ON ssn+DAY(date) TAG mytag
  211.  
  212.     In order to get Rushmore to work with these indexes, the index expression
  213.     must match the expression you are locating on.
  214.  
  215. ******
  216. 3.0 Using functions in indexes.
  217.     As you've seen from the preceeding section, you can utilize any FoxPro
  218.     function in your index.  The question as far as Rushmore is concerned
  219.     is - should you?
  220.  
  221.     In most cases, the answer is yes.  The caveat here is that when you're
  222.     designing your database, you need to be aware of the trade-off between
  223.     getting better speed through Rushmore, and taking longer to update your
  224.     indexes when you change or add records.
  225.  
  226.     The other major pitfall with using functions in your indexes is how you
  227.     solve for the solutions later.  Most people, if they have an index on
  228.     UPPER(lname+fname), and two input fields, m.last and m.first, will
  229.     attempt to:
  230.  
  231.     LOCATE FOR UPPER(lname+fname) = UPPER(m.last+m.first)
  232.  
  233.     This will work, and Rushmore will optimize it, but you won't see any
  234.     real speed increase.  The reason for this is because the
  235.     UPPER(m.last+m.first) is evaluated for EVERY RECORD in the database.
  236.  
  237.     In order to properly utilize this index, you should:
  238.  
  239.     m.search = UPPER(m.last+m.first)
  240.     LOCATE FOR UPPER(lname+fname) = m.search
  241.  
  242. ******
  243. 3.1 Using user-defined functions in indexes.
  244.     Rushmore is able to utilize FoxPro functions in index expressions,
  245.     and it is also able to utilize user-defined functions (udf's) in
  246.     its optimization process.  There are several things you have to be
  247.     aware of, though:
  248.  
  249.     1) The speed that Rushmore can process is limited by how fast your
  250.        function executes.
  251.  
  252.     2) Be extremly careful about what your function does.  Your function
  253.        should make no guesses about the current operating environment, the
  254.        value of SET EXACT, SET ORDER, SET RELATION, etc.
  255.  
  256.     3) Your function ***MUST NOT*** modify any databases.  Doing so can
  257.        cause everything from "something strange is happening" to "FoxPro
  258.        must be buggy - it gets stuck in an endless loop."
  259.  
  260.     4) Be extremly careful about any variables you function may modify.
  261.        It's extremly easy to get the "wrong" result when your function
  262.        modifies one of your search variables.
  263.  
  264.     5) Your function ***MUST NOT*** move the record pointer in any database
  265.        hooked into the database you're using with SET RELATION.  It ***MUST
  266.        NOT*** move the record pointer in the current database.
  267.  
  268. ******       
  269. 3.2 Using functions from .plb files in indexes.
  270.     As long as the function in the .plb is "well behaved", there should be
  271.     no problems using it.  Remember the points in section 3.1, though.
  272.  
  273. ******
  274. 4.0 What is an "optimizable expression"?
  275.     An optimizable expression is any expression that Rushmore can attempt
  276.     to use.  How well Rushmore can work with the expression determines if
  277.     the expression is fully, partially, or non-optimizable.
  278.  
  279.     All of the examples used up to now were either fully optimizable, or
  280.     non optimizable.  Expressions that may be partially optimizable generally
  281.     take the format of:
  282.  
  283.     LOCATE FOR lname = "Cochran" AND ssn = 987654321
  284.  
  285. ******
  286. 4.1 Fully optimizable expressions.
  287.     In order for our last LOCATE statement to be fully optimizable, we
  288.     would have to:
  289.  
  290.     INDEX ON lname TAG lname
  291.     INDEX ON ssn TAG ssn
  292.  
  293.     This is the "best" solution, and will allow Rushmore to find the records
  294.     the fastest.
  295.  
  296. ******
  297. 4.2 Partially optimizable expressions.
  298.     If we had the index on ssn, but no index on lname, then our expression
  299.     would partially optimizable.  Rushmore would activate to locate the
  300.     records which matched our ssn, and then treat the rest of the expression
  301.     as a non-optimizable search.  Note that Rushmore is smart enough that
  302.     it will solve for the optimizable portions first, and then perform
  303.     the rest of the search on the subset of records it already has.
  304.  
  305. ******
  306. 4.3 Non-optimizable expressions.
  307.     A non-optimizable expression is one that Rushmore can't help.  You want
  308.     to avoid these expressions in all but the most extreme cases.  The
  309.     reason is that FoxPro will search every record in the database,
  310.     starting at RECNO() = 1.
  311.  
  312.  
  313. ******
  314. 5.0 Rushmore and the SEEK statement.
  315.     Basically, the SEEK statement, and the SEEK() function don't interact
  316.     with Rushmore at all.  This can be both a blessing and a curse.  For
  317.     simple indexes, you can get faster results out of SEEK than you
  318.     can out of Rushmore.  But SEEK will not allow you to search on
  319.     multiple fields...
  320.  
  321. 5.1 Rushmore and the LOCATE and SCAN statements.
  322.     Rushmore will almost always speed up your queries when using LOCATE FOR
  323.     or SCAN FOR statements.  To get the best use of Rushmore in these
  324.     statements, you should build simple indexes on the fields you will
  325.     most often search through.
  326.  
  327. 5.2 Rushmore and the SET ORDER TO statement.
  328.  
  329.     [Many thanks to Evan Simpson (evan@access.digex.net) for helping clear
  330.     up a misconception about the SET ORDER TO statement for me.]
  331.  
  332.     (1)The speed of the search will be slower.  This is true whether you
  333.        are using Rushmore or not.
  334.     (2)The first record Rushmore locates (i.e. LOCATE FOR foo = "bar")
  335.        will be the lowest numbered record in the database [RECNO()] that
  336.        matches the search criteria, regardless of the SET ORDER TO clause.
  337.  
  338.        For example, let's assume we have:
  339.        RECNO()   FOO BAR
  340.              1   AAA BBB
  341.              2   AAA CCC
  342.              3   AAA DDD
  343.              4   AAA CCC
  344.  
  345.        If you:
  346.        SET ORDER TO BAR
  347.        LOCATE FOR bar = "CCC"
  348.  
  349.        Rushmore will locate RECNO() 2, and then RECNO() 4.
  350.  
  351.        If you:
  352.        SET ORDER TO bar
  353.        LOCATE FOR foo = "AAA"
  354.  
  355.        Then Rushmore will locate records in the following order:
  356.        RECNO() 1
  357.        RECNO() 2
  358.        RECNO() 4
  359.        RECNO() 3
  360.  
  361.        Of course, you shouldn't program with this in mind, because Microsoft
  362.        may change it in future releases.
  363.  
  364. 5.3 Rushmore and the SET RELATION TO statement.
  365.     Beware of attempting to use Rushmore along with SET RELATION.  Due
  366.     to the constraints of the SET RELATION statement, Rushmore will
  367.     either not work at all, or will only work in very limited cases.
  368.  
  369. 5.4 Rushmore and the SET DELETED statement.
  370.     Rushmore can optimize a query for deleted() IF you index on deleted().
  371.     If your database contains a large number of deleted records, you
  372.     can help Rushmore out by either indexing on deleted(), or by using
  373.     the SET DELETED OFF statement before you invoke Rushmore.
  374. -- 
  375. =kcochran@nyx.cs.du.edu | B(0-4) c- d- e++ f- g++ k(+) m r(-) s++(+) t | TSAKC=
  376. =My thoughts, my posts, my ideas, my responsibility, my beer, my pizza.  OK???=
  377. =                          "Love can break your heart"                        =
  378.  
  379.